Text authorization for mobile payments

ABSTRACT

A system and method enables trusted sources to easily approve requests for money transfers by simply typing in a yes or equivalent.

RELATED APPLICATIONS

This application claims benefit of U.S. Provisional Application No.61/111,601, filed Nov. 5, 2008, the entire disclosure of which isincorporated herein by reference.

BACKGROUND

1. Field of the Invention

The present invention generally relates to financial transactions andmore particularly to facilitating mobile on-line financial transactionsthrough an on-line payment provider.

2. Related Art

With the ever-increasing popularity of the Internet and of Internetcommerce, both consumers and sellers are using the Internet tofacilitate financial transactions between parties, whether they beindividuals or companies. In on-line financial transactions, consumersmay use third-party payment service providers to transfer money throughelectronic communications with others over electronic networks, such asthe Internet. The money transfer may be for payment of goods or servicesor between family members and friends. The third-party payment providersprovide an infra-structure, software, and services that enable users tomake and receive payments. The payments may be credit card payments,electronic bank transfers, or other payment techniques offered by thethird-party payment provider. One payment technique may be transferringmoney from an account held by the payment provider, as opposed totransferring credit from an outside credit card company or an outsidefinancial institution or bank. Transferring money held in the paymentprovider account may be cheaper for a user because it avoids certaintransaction fees or interest payments that may be incurred whentransferring money or making a payment from an outside credit or bankinginstitution.

When one user desires to transfer money to another user, there istypically a series of requests and confirmations, including enteringpersonal identification numbers (PINs), that one or both users mustperform. This ensures that money is not fraudulently or mistakenlytransferred from one account or user to another. However, requiringusers to go through such a series of actions may be cumbersome andtime-consuming. This can be especially true with users that areperforming the transactions via mobile devices due to factors such assmaller keypads, time delays, and less stability of the device whencompared with desktop devices. With increased use and proliferation ofmobile devices in Internet commerce, there is a need for a simple, yetsecure, method to perform financial transactions between users usingmobile and other computing devices.

SUMMARY

According to one embodiment, a user (payer) sends text message via ShortMessage Service (SMS) on the payer's mobile device to initiate a moneytransfer. The text message may simply identify the dollar amount and therecipient, such as a name, phone number, or email. If the recipientidentifier is known to the payment provider as a “trusted” source, suchas someone previously identified as such by the payer to the paymentprovider or someone who the payer has previously sent money to, thepayment provider responds with a text message to the payer askingwhether the specified dollar amount should be sent to the recipient. Thepayer can then simply type “yes” or “y” to confirm and make the payment.If the recipient is not a “trusted” recipient, the payment provider asksthe payer to other authorize the transaction through a shared secret(password or PIN). For example, the payment provider could contact therecipient to ask for a PIN, which it verifies first before sending thepayment. The payment provider may then ask the payer if the payer wantsto add the recipient as a “trusted” source for future payments.

According to another embodiment, a user (recipient), such as a child,asks their parent (payer) for money via SMS, e.g., by typing “get 10,”“get 10 from mom,” “get 10 from dad,” or “get 10 from [phone number ofparent].” Based on the child's phone number, the payment providerdetermines if the parent is a trusted source for quick approvals.(Family members may be assumed as trusted until otherwise indicated). Ifso, the payment provider sends a text message to the parent, asking forapproval of the requested transfer from the child. The parent can thensimply type a “yes” or “y” to initiate the transaction. The requestedamount (e.g., $10) is then transferred form the parent's account to thechild's account. The parent and/or child may be notified via text thatthe transfer has been completed. If the parent denies the request bytyping a “no” or “n,” the payment provider notifies the child and/orparent that the request has been canceled. If the parent is not part ofthe payment provider system as a trusted source for quick approvals, thepayment provider can text or email the parent and obtain desiredinformation such as a PIN. The parent can then be asked whether theywant to be in the child's trusted source for quick approvals.

These type of quick approvals (simply typing “yes,” “y,” or “9”(shortcut for “y”) for money transfers enables users to more quickly andeasily effect money transfers between trusted sources, such as parentand child, with minimal risks of fraudulent transfers.

These and other features and advantages of the present invention will bemore readily apparent from the detailed description of the embodimentsset forth below taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a flowchart showing steps used to facilitate a textauthorization for an on-line financial transaction according to oneembodiment;

FIG. 2 is a flowchart showing steps used to facilitate a textauthorization for an on-line financial transaction according to anotherembodiment;

FIG. 3 is a block diagram of a system used for facilitating an on-lineaccount according to one embodiment; and

FIG. 4 is a block diagram of one embodiment of a system that can be usedto implement one or more components of the system in FIG. 3.

Exemplary embodiments and their advantages are best understood byreferring to the detailed description that follows. It should beappreciated that like reference numerals are used to identify likeelements illustrated in one or more of the figures, wherein showingstherein are for purposes of illustrating exemplary embodiments and notfor purposes of limiting the same.

DETAILED DESCRIPTION

FIG. 1 is a flowchart 100 showing one embodiment of using textauthorization to facilitate an on-line financial transaction, such as amoney transfer, using mobile devices, where the payer initiates therequest. In step 102, a user (payer) sends a text message to a paymentprovider, such as PayPal, Inc., from his computing device, such as amobile phone, using SMS. The text may simply be “send 10 to Matt.” Thepayment provider determines, at step 104, whether “Matt” is in thepayer's “trusted” list, which identifies people/merchants that the payerhas designated as ones that do not require authentication, such as aPIN, for an on-line money transfer. Note that “trusted” list or sourceis defined, in one embodiment, as people/merchants identified by eithera payer or a recipient as ones that can be approved for a money transferwithout requiring a PIN, and typically, only require an identificationor confirmation for the transfer to be made. The payer may initiallyidentify these trusted sources to the payment provider, such as withname, phone number, and/or email. The payer may also add, drop, or edittrusted sources at any time by contacting the payment provider. If“Matt” is uniquely identified as a trusted source in step 104, thepayment provider transfers the requested amount (in this case $10) fromthe payer's account to Matt's account in step 106. A notification may besent from the payment provider to the payer and/or the recipient.

If the intended recipient is not uniquely identified as a trusted sourceof the payer (e.g., when there are multiple matches or ambiguity withthe intended recipient's information), the payment provider determinesif there are multiple matches for the intended recipient in step 108.For example, the payer's trusted source list may include multiple “Matt”names, “Matthew”, “matt” within a name, such as “Jody Smatter,” or anyother possible matches with “matt.” Other ambiguities or matches mayoccur with other recipient designations, such as email, etc. Themultiple matches may be from the payer's trusted source list or simplyfrom people that the payer has conducted transactions with over a givenperiod of time (e.g., 1 year). If there are multiple matches, then thepayment provider compiles the list of matches and transmits that list tothe payer at step 110. For example, the payer may be provided, at hismobile device, a list of several possible matches for Matt, eachcorresponding to a number. The payer then determines which one is theintended recipient and selects the desired one in step 112. Theselection can be simply replying to the payment provider and typing inthe appropriate number, such as “2” for “Matt Jones.” If none of theselections is the one the payer wants, the payer can reply with contactinformation, such as a phone number for the intended recipient. Thepayment provider can then call that number to obtain desiredinformation. Once the proper and correct recipient is identified, thepayment provider transfers the requested money amount from the payer'saccount to the account of the intended recipient. Notifications may besent to the payer and/or the recipient after transfer. If the recipientwas not in the payer's trusted source, the payment provider can send arequest to the payer to add the recipient to the list for future quickapproval transactions.

If, as determined in step 108, there are not multiple matches for theintended recipient, the payment provider determines, at step 114,whether there is a single match from sources who the payer has conductedtransactions with over a certain period of time, such as one year. Ifthere is a match, e.g., the payer conducted one or more transactionswith “Matt” over the past year, but “Matt” is not in the payer's trustedsource list, the payment provider sends a text message to the payer, instep 116, asking the payer to confirm the transaction. The text messagemay be “send 10 to Matt Jones.” The payer, at step 118, can thenconfirm, deny, or reply with a different phone number. If confirmed,such as by typing in a “yes,” “y,” or “9,” the payment provider transferthe requested amount in step 106 to Matt Jones. The payment provider cansend a message to the payer asking whether Matt Jones is to be added tothe payer's trusted source list. If, as determined in step 118, thepayer denies the request, such as by typing “no”, “n,” or “6,” thetransaction is canceled at step 120.

If, as determined in step 114, the payer's intended recipient does notmatch anything in the payment provider's system for the payer, thepayment provider sends a text message to the payer asking for additionalinformation about the recipient, in step 122. A “no” match may resultfrom the payer never having conducted any transactions with therecipient, the payer mis-typing the recipient's information, or thepayer not having conducted any transactions with the recipient within acertain period of time, such as 3 years. The request for information instep 122 may include asking the payer for an email or phone number forthe intended recipient. The payer enters and transmits the requestedinformation, which the payment provider uses to uniquely identify theintended recipient. Since the recipient is not yet a trusted recipientfor this sender, the payment provider then asks the payer for anauthorization of the transaction through a shared secret (PIN orpassword). This may include calling the payer by IVR (Interactive VoiceResponse) or sending a link to the payer via SMS to collect thecredentials online. If confirmed, the requested funds are transferred,and the payer can be asked whether the recipient is to be added to thetrusted source list. If denied, the transaction is canceled. As withtransactions discussed herein, the payment provider may send a notice tothe payer and/or the recipient that the requested funds have beentransferred. In other embodiments, the payer and/or the recipient canrequest the payment provider call them for various steps discussedherein if security is an issue. This can be done, for example, by thepayer/recipient sending a “1” as a reply to a request for a call-back.

FIG. 2 is a flowchart 200 showing another embodiment of using textauthorization to facilitate an on-line financial transaction, such as amoney transfer, using mobile devices, where a recipient initiates therequest. In step 202, a user (recipient) sends a text message to apayment provider, such as PayPal, Inc., from his computing device, suchas a mobile phone, using SMS. The user in this example is a childrequesting a money transfer from his parent(s), although this embodimentis not limited to a child/parent transaction. The text message may be“get 10,” “get 10 from [parent's phone number],” “get 10 from dad,” or“get 10 from mom.” The payment provider, at step 204, determines whetherthe recipient has a trusted source for quick approval. If the child'sphone number is associated with only one trusted source, then a “get 10”message would simply require the payment provider to check if the childhas a trusted source. If there is not enough information in the requestor if the payer is not in the child's trusted source, the paymentprovider sends a message for additional information in step 206. Whenthere is insufficient information, the payment provider may send amessage to the child asking for additional information, such as a nameor phone number of the payer. When there is not a match, the paymentprovider may contact the payer, such as by email, text, or call, toobtain additional information. The payer may be asked for accountinformation and whether the payer wants to be added to the child'strusted source list for quick approvals of money requests. The paymentprovider may also send a text message to the child informing the childthat the parent has been notified, but they are not yet on the quickapproval list or have not turned on this feature. Depending on theactions, the payment provider may then make the requested money transferor cancel the transaction, notifying one or both parties if desired.

If, as determined in step 204, the payer is a trusted source, thepayment provider sends a confirmation request to the payer (e.g, parent)in step 208. The request may be an SMS message such as “transfer 10 toson” or “transfer 10 to [phone number of child].” The payer then replieswith a “y” or equivalent to confirm the request. If the request fortransfer is confirmed, as determined in step 210, the payment providertransfer the specified amount from the payer's account or otherdesignated account to the recipient's account in step 212. The paymentprovider, at step 214, may then send the payer and/or the recipient amessage indicating that the funds have been sent. If the request fortransfer is not confirmed at step 210, the payment provider determineswhether the request was actually denied or just not responded to at step216. If the former, the money transfer request is canceled in step 218,and a message may be sent by the payment provider to the requestor(intended recipient) and/or the intended payer in step 220 that therequest has been denied and canceled by the payer.

If the confirmation has not been confirmed or denied, the payer maysimply have not responded to the request. If that is the case, asdetermined at step 216, the payment provider determines whether therequest has expired at step 222. Expiration may be when a response(confirm or deny) has not been received for a given period of time, suchas one day or one week. Note that one possible requirement (of thisembodiment) of the payment provider is that only one request can bepending or processed at a time. For example, if a first request formoney is made without a response by the payer and then a second requestis made while the first request is still pending (i.e., not expired oracted upon (confirmed or denied)), the payment provider may send amessage to the requestor in response to the second request. The messagemay be that the first request is still pending and that the secondrequest will not be transmitted or accepted until the first request hasexpired or been responded to. The message may also ask the requester ifthe requester desires to cancel the first request, cancel the secondrequest, or cancel both requests and send a new request. In otherembodiments, multiple requests could be handled at the same time but thepayee (parent) would need to specify which payment to complete. Forexample, when replying with “y,” the parent would need to be morespecific and specify which transaction should be completed. This couldbe done through a text such as “y first.”

If a request has expired, the payment provider sends a message, in step224, to the payer, such as a reminder. In one example, the paymentprovider sends the payer a text message asking the payer if the payerwants to send the requested amount to the initial requester (e.g., thechild). The payer can confirm with a “yes” or equivalent to create thenew payment. Alternatively, the payer can be asked to forward themessage to the payment provider to create the new payment request. Ifconfirmed, as determined in step 226, the payment provider transfers therequested amount in step 212 and sends a message to the payer and/orrecipient in step 214. If the request is not confirmed (e.g., by anothernon-response or an actual denial), the payment provider cancels therequest in step 218 and sends a message to the payer and/or recipient instep 220. Another option for response is that the payer (parent in thiscase) may respond with an affirmation of the transaction but for a loweramount. For example, the parent may reply to the request with “yes 10”to only authorize ten dollars instead of the original requested amount.

In various embodiments, the payment provider may offer the recipient orpayer different options. For example, the payer or parent may have aprofile-level setting that allows them to choose whether thequick-approval feature is turned off or on. The feature may beselectively turned on for specific recipients. A limit on the amount apayer can approve through this text process can be set, such as no morethan $50 each day, or no more than $100 each week, or no more than $300each month. When limits are met, the payment provider may send a textmessage to the requestor and/or the payer. In different embodiments, thepayer may be given the option of bypassing the pre-set credit limit,either only for the current transaction or modifying the limit forfuture requests.

FIG. 3 shows one embodiment of a block diagram of a system 300configured to facilitate financial transactions over a network 302 toperform the steps described above with respect to FIGS. 1 and 2. Asshown in FIG. 3, system 300 includes at least one first user device 304,one second user device 306, and at least one payment provider server 308in communication over network 302. In one embodiment, network 302 may beimplemented as a single network or a combination of multiple networks.For example, network 302 may include the Internet and/or one or moreintranets, landline networks, wireless networks, and/or otherappropriate types of communication networks. In another example, thenetwork may comprise a wireless telecommunications network (e.g.,cellular phone network) adapted to communicate with other communicationnetworks, such as the Internet.

In one embodiment, first user device 304 may be implemented using anyappropriate combination of hardware and/or software configured for wiredand/or wireless communication over network 302. For example, first userdevice 304 may be implemented as a computing device of a first user 310in communication with network 302, such as a wireless telephone (e.g.,cell phone), personal digital assistant (PDA), notebook computer, and/orvarious other generally known types of computing devices. First userdevice 304 may include one or more browser applications 312 which may beused, for example, to provide a user interface to permit the first user310 to browse information available over network 302. For example,browser application 312 may be implemented as a web browser to viewinformation available over the Internet or access a payment providersite or account.

First user device 304 may also include a service application 314 forfacilitating financial transactions on network 302. In an exampleembodiment, the service application 314 comprises a software program orprograms, such as a graphical user interface (GUI), executable by aprocessor that is configured to interface and communicate with a seconduser 322 and with payment provider server 308 via network 302. In anexample embodiment, the service application may be resident on the userdevice or accessed by a user through network 302. First user 310 mayinitiate a request for money from second user 322 or a request totransfer money to second user 322 through payment provider server 308through applications on first user device 304.

In an example embodiment, service application 314 may be accessed usinga protocol such as a WSDL (web services definitional language), SOAP(simple object access protocol), API (application program interface), orthe like. The applications may be initiated from a remote call procedurefrom an API or other protocol. The remote calls may be initiated from aprogram resident on the user device or from a third-party platform orwebsite, for example a social networking site such as FACEBOOK, MYSPACEor any other website that may feature access to a payment providerservice application.

When installed on or accessed by first user device 304 and run fromfirst user device 304, service application 314 is configured to provideand display payment services mechanism or mechanisms, such as an image,icon, radio button, dialogue box or other graphical user interface (GUI)on a display component (e.g., monitor) of first user device 304. Ingeneral, the GUI represents a program, application, command, link to aweb page, etc., wherein first user 310 may select a payment service,shop, conduct other payment processing services. The GUI may include theoption of initiating a quick approval for sending or receiving money bytaking a certain action, for example by clicking on a related icon,radio button, link or other button or representation using a cursorcontrol component (e.g., mouse) or keyboard. The user may then type in asuitable text message to initiate the quick approval process.

In an example embodiment, in which first user 310 has not yetestablished an account or user record with payment provider server 308,upon installation of service application 314, first user 310 may beprompted to establish a user account with payment provider server 308,wherein first user 310 may use first user device 304 to access paymentprovider server 308 via network 302. When establishing a user account,first user 310 may be asked to provide personal information, such asname, address, phone number, user name, e-mail address, password, PIN,etc., and financial information, such as banking information, creditcard information, etc.

Payment provider server 308 may create a user account 324 for each user310. The user account may include account information 326, includingthird party funding source information 328 used to transfer or receivemoney, and a user status 330. Third-party funding source information 328may include the identity of sources, routing numbers, account numbersand the like. Information related to the availability of funds and/orcredit may be stored as part of a user status.

First user device 304 may include other applications 318 as may bedesired in particular embodiments to provide additional featuresavailable to first user 310. For example, such other applications 318may include security applications for implementing consumer-sidesecurity features, programmatic user applications for interfacing withan appropriate protocol such as WSDL, SOAP or API or the like overnetwork 302 or various other types of generally known programs and/orapplications.

First user device 304 may also include one or more user identifiers 320,which may be implemented, for example, as operating system registryentries, cookies associated with browser application 312, identifiersassociated with hardware of first user device 304, or various otherappropriate identifiers. User identifier 320 may include attributesrelated to the user, such as personal information (e.g., a user name,password, photograph image, biometric ID, address, phone number, etc.)and banking information (e.g., banking institution, credit card issuer,user account numbers, security information, etc.). In variousimplementations, user identifier 320 may be passed with a request totransfer or receive funds executed by payment provider server 308, anduser identifier 320 may be used by payment provider server 308 toassociate first user 310 with a particular user account 324 maintainedby payment provider server 308.

In one embodiment, second user device 306 may be similar to first userdevice 304. It may be owned, operated and maintained, for example, by afinancial or payment services provider with user account 324 stored onpayment provider server 308. Second user device 306, browser application312, service application 314, other applications 318, and useridentifier 320 may implemented similarly as described above with respectto the first user device. Service application 314 of second user device306 may also enable the second user to initiate, process, and approve ordeny quick-approval transactions discussed above with respect to FIGS. 1and 2.

Payment provider server 308 may be maintained, for example, by an onlinepayment service provider, such as PayPal, Inc. of San Jose, Calif.,which may provide payment processing for online transactions on behalfof first user 310 and second user 322 through their respective devices304 and 306. In this regard, payment provider server 308 includes one ormore service applications 332, which may be configured to interact withthe devices 304, 306 over network 302 to facilitate the financialtransactions (including requests for money transfers between trustedsources).

Payment provider server 308 may be configured to maintain a plurality ofuser (first and second users) accounts 324, each of which may includeaccount information 326 associated with individual users, includingfirst user 310 and second user 322 associated with the devices 304, 306,respectively. For example, account information 326 may includeinformation, such as one or more account numbers, passwords, credit cardinformation, banking information, user name, or other types of financialinformation, which may be used to facilitate online transactions betweenfirst user 310 and second user 322. User accounts 324 may include memoryin individual seller accounts that stores the shared secret from theseller.

User funds accounts 336 may be maintained by payment provider server308, which represent funds that are held by the payment provider. Thefunds in the account may represent funds received in previoustransactions and/or funds placed in the account by a user for accessthrough the payment provider services.

Thus, in one embodiment, first user 310 communicates to payment providerserver 308 from first user device 304 via network 302, instructing atransfer of funds held in a first user account of user funds 336 ofpayment provider server 308 to be transferred to the second user orrequesting a request of funds held in a second user account of userfunds 336 to be transferred to the first user. Funds can be transferredfrom accounts maintained by payment provider server 308 or from thirdparty funding sources 338, such as linked bank accounts or credit cards.If an instruction or request is confirmed by the simple textauthorization discussed herein, payment provider server 308 transfersthe designated amount of funds to the appropriate account, held by thefirst or second user.

FIG. 4 is a block diagram of a computer system 400 according to oneembodiment, which may be suitable for implementing embodiments ofvarious aspects of this disclosure, including, for example, device 304,device 306 and/or payment provider server 308. In variousimplementations of various embodiments, device 304 and/or device 306 maycomprise a personal computing device, such as a personal computer,laptop, PDA, cellular phone or other personal computing orcommunications devices. Payment provider server 308 may comprise anetwork computing device, such as one or more servers, computer orprocessor combined to provide the payment services. Thus, it should beappreciated that devices 304, 306, and/or payment provider server 308may be implemented as computer system 400 in a manner as follows.

In one embodiment, computer system 400 may include a bus 402 or othercommunication mechanism for communicating information, whichinterconnects subsystems and components, such as a processing component404 (e.g., processor, micro-controller, digital signal processor (DSP),etc.), a system memory component 406 (e.g., RAM), a static storagecomponent 408 (e.g., ROM), a disk drive component 410 (e.g., magnetic oroptical), a network interface component 412 (e.g., modem or Ethernetcard), a display component 414 (e.g., CRT or LCD), an input component416 (e.g., keyboard or keypad), and/or a cursor control component 418(e.g., keys, mouse, or trackball). In one embodiment, disk drivecomponent 410 may comprise a database having one or more disk drivecomponents.

Computer system 400 may perform specific operations by processor 404executing one or more sequences of one or more instructions contained insystem memory component 406, according to steps described above withrespect to FIGS. 1 and 2. Such instructions may be read into systemmemory component 406 from another computer readable medium, such asstatic storage component 408 or disk drive component 410. The variousstorage or memory components may be used to store information abouttrusted sources for the quick-approval process. In other embodiments,hard-wired circuitry may be used in place of or in combination withsoftware instructions to implement the invention.

Logic may be encoded in a computer readable medium, which may refer toany medium that participates in providing instructions to processor 404for execution. Such a medium may take many forms, including but notlimited to, non-volatile media, volatile media, and transmission media.In various implementations, non-volatile media includes optical ormagnetic disks, such as disk drive component 410, volatile mediaincludes dynamic memory, such as system memory component 406, andtransmission media includes coaxial cables, copper wire, and fiberoptics, including wires that comprise bus 402. In one example,transmission media may take the form of acoustic or light waves, such asthose generated during radio wave and infrared data communications.

Some common forms of computer readable media includes, for example,floppy disk, flexible disk, hard disk, magnetic tape, any other magneticmedium, CD-ROM, any other optical medium, punch cards, paper tape, anyother physical medium with patterns of holes, RAM, PROM, EPROM,FLASH-EPROM, any other memory chip or cartridge, carrier wave, or anyother medium from which a computer is adapted to read.

In various example embodiments, execution of instruction sequences forpracticing embodiments of the invention may be performed by computersystem 400. In various other embodiments, a plurality of computersystems 400 coupled by communication link 420 (e.g., network 110 of FIG.1, LAN, WLAN, PTSN, or various other wired or wireless networks) mayperform instruction sequences to practice the invention in coordinationwith one another.

Computer system 400 may transmit and receive messages, data, informationand instructions, including one or more programs (i.e., applicationcode) through communication link 420 and communication interface 412.Received program code may be executed by processor 404 as receivedand/or stored in disk drive component 410 or some other non-volatilestorage component for execution.

Where applicable, various embodiments provided by the present disclosuremay be implemented using hardware, software, or combinations of hardwareand software. Also, where applicable, the various hardware componentsand/or software components set forth herein may be combined intocomposite components comprising software, hardware, and/or both withoutdeparting from the spirit of the present disclosure. Where applicable,the various hardware components and/or software components set forthherein may be separated into sub-components comprising software,hardware, or both without departing from the scope of the presentdisclosure. In addition, where applicable, it is contemplated thatsoftware components may be implemented as hardware components andvice-versa.

Software, in accordance with the present disclosure, such as programcode and/or data, may be stored on one or more computer readablemediums. It is also contemplated that software identified herein may beimplemented using one or more general purpose or specific purposecomputers and/or computer systems, networked and/or otherwise. Whereapplicable, the ordering of various steps described herein may bechanged, combined into composite steps, and/or separated into sub-stepsto provide features described herein.

The foregoing disclosure is not intended to limit the present inventionto the precise forms or particular fields of use disclosed. It iscontemplated that various alternate embodiments and/or modifications tothe present invention, whether explicitly described or implied herein,are possible in light of the disclosure.

Having thus described embodiments of the invention, persons of ordinaryskill in the art will recognize that changes may be made in form anddetail without departing from the scope of the invention. Thus, theinvention is limited only by the claims.

1. A method of facilitating an on-line transaction, comprising:receiving a text request for a money transfer from a first user;determining whether a second user is a trusted source of the first user;and executing the money transfer if the second user is a trusted sourceof the first user without the need of a PIN or a password.
 2. The methodof claim 1, wherein the money transfer is from the first user to thesecond user.
 3. The method of claim 1, wherein the money transfer isfrom the second user to the first user.
 4. The method of claim 3,further comprising: sending a text confirmation request to the seconduser; and receiving an equivalent yes or no text reply from the seconduser.
 5. The method of claim 2, further comprising: sending a textconfirmation request to the first user if the second user is not atrusted source of the first user; and executing the money transfer ifthe first user replies with a text confirmation to the request.
 6. Themethod of claim 5, wherein the text confirmation is an equivalent yes.7. The method of claim 5, further comprising sending a text message tothe first user whether to add the second user as a trusted source. 8.The method of claim 4, further comprising determining whether the textconfirmation request has expired.
 9. The method of claim 8, furthercomprising sending a reminder text request to the second user if thetext confirmation request has not expired and no response from thesecond user has been received.
 10. The method of claim 4, furthercomprising sending a text message to the second user whether to add thesecond user as a trusted source.
 11. The method of claim 1, wherein thetext request is sent from a mobile device.
 12. The method of claim 4,wherein the text reply is sent from a mobile device.
 13. The method ofclaim 5, wherein the text confirmation is sent from a mobile device. 14.A computer-readable medium containing instructions that cause a serviceprovider facilitating financial transactions over a network to perform amethod comprising: receiving a text request for a money transfer from afirst user; determining whether a second user is a trusted source of thefirst user; and executing the money transfer if the second user is atrusted source of the first user.
 15. The computer-readable medium ofclaim 14, wherein the money transfer is from the first user to thesecond user.
 16. The computer-readable medium of claim 14, wherein themoney transfer is from the second user to the first user.
 17. Thecomputer-readable medium of claim 16, wherein the method furthercomprises: sending a text confirmation request to the second user; andreceiving an equivalent yes or no text reply from the second user. 18.The computer-readable medium of claim 15, wherein the method furthercomprises: sending a text confirmation request to the first user if thesecond user is not a trusted source of the first user; and executing themoney transfer if the first user replies with a text confirmation to therequest.
 19. The computer-readable medium of claim 18, wherein the textconfirmation is an equivalent yes.
 20. The computer-readable medium ofclaim 18, wherein the method further comprises sending a text message tothe first user whether to add the second user as a trusted source. 21.The computer-readable medium of claim 17, wherein the method furthercomprises determining whether the text confirmation request has expired.22. The computer-readable medium of claim 21, wherein the method furthercomprises sending a reminder text request to the second user if the textconfirmation request has not expired and no response from the seconduser has been received.
 23. The computer-readable medium of claim 17,wherein the method further comprises sending a text message to thesecond user whether to add the second user as a trusted source.